An increasing amount of applications and functionality is being offered in the form of services over various networks. By providing functionality as a service, a user or customer can simply subscribe to or otherwise access the functionality, while allowing someone else to maintain, host, update, and otherwise provide the functionality as a service. When providing functionality in the form of services, however, the service provider may have little control over which version of the service a user or customer is using. While a service provider can simply stop supporting previous versions of a service, such an approach can be undesirable from a business standpoint. For example, if a user has a data file created by previous version 1 of a service, but that data file is not compatible with current version 10 of a service, then the user might have no way to easily recover that data. Further, users might migrate to other services from other providers that do not require frequent updating, etc. It thus can be desirable in certain situations to ensure that each new version of a service is backwards compatible with at least some of the previous versions.
One way to address these differences is to include logic in the service that can handle data, requests, and other information for multiple versions. For example, each version can include logic for determining how requests need to be handled based upon the version the user is currently operating or expecting. In a basic example, this can include a series of “If . . . then . . . ” or similar statements as known in the art for handling different situations. If a service is to report back a series of data values, the service might need to include a series of statements for each data value, such as “If version 1 then report as a string” and “If version 2 then report as an integer”, and so on. This can become extremely long and complex as the number of variables and the number of versions increases. In some cases, a new version of a service might be released every six weeks, with previous versions being supported for several years before being retired. In this case, there can be tens or even hundreds of different versions, with differences between all variations having to be handled through logic. For potentially thousands of elements or more, this gets to be way too complex and difficult to maintain. Further, such a solution is not flexible or scalable.